0.18 is out. Please check the new api . Do you mind to volunteer as a maintainer for the plugin?

OK, I'll update this plugin later, and I'll maintain this plugin.

Hey thank you. But wait theres another yscode plugin too. Maybe you could colaborate

#132

@corvofeng are you still interested in getting this upstream? I dont know what @mparati31 and @Sharsie think about this one, but it would be cool if you guys could objectively argue which plugins do the job best or probably even better merge the best parts.

@ManuelSchneid3r This implementation is kinda confusing, there's a mix of storage configs, though it's always using the sqlite under the hood. The code could use some polishing

What I can say is that the sqlite definitely contains more data to open recent paths, than the json storage. I do not know if there are any disadvantages to that though (db locking, performance), would need to be tested

Needless to say, what I would miss from both @mparati31 and @corvofeng implementation as they are now, is the support of searching through Project Manager extension and maybe more importantly accent normalization of the query input mentioned in the previous PR. Although my implementation does include that, I would say it needs even more polishing from someone well familiar with python (which I'm not)

In my opinion, some kind of collaboration/combination would be the best solution
@mparati31 implementation is the most polished one
@corvofeng implementation is the simplest + using sqlite (which I don't know if it's a good thing or a bad thing)
Mine is the most feature rich, but needs refactoring.

All implementations could use an update to the new API as well

At this stage, I would merge neither of the three :)
I would offer to start off on some collaborated implementation, if it weren't for the fact that we are finishing a house atm and I have no time for anything until the summer. Seeing there's little progress here though, I might be done with the house earlier than anything gets merged.

I am going to close this due to the conflicts. Note that I dont want to stop the discussion about this plugin though.

maybe more importantly accent normalization

why exactly is this so important? I mean I see the need for it, but this should rather be implemented globally. Theres an issue for it.

That is a valid point, although I would argue that it should be up to the plugin implementation whether it wants to normalize the query or not.

If you were to provide query normalization by default, you would have to provide a normalizer as well, so that the plugin developers can utilize the same implementation and don't run into mismatches where they compare the normalized query string to their own non-normalized results (e.g. this plugin searches through projects which could contain accents), or if they do normalize, their implementation could differ from the one that handles the query and thus failing the matches as well.

I'll think on this and checkout the other issue later.